-
Notifications
You must be signed in to change notification settings - Fork 358
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Auto-Generated Stubs for Python Bindings #2028
base: main
Are you sure you want to change the base?
Conversation
|
Seems like, when building through The stubgen command needs to be executed from where the .pyd files are. For that, I currently set the |
) | ||
endif () | ||
endif() | ||
|
||
if(MATERIALX_INSTALL_PYTHON AND PYTHON_EXECUTABLE AND NOT SKBUILD) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you need to move this before stubgen, so it get's run after install.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
However to include the stubs in the package itself, You need to repackage.
I think the least number of steps is
- run this install step to produce the locally installed MaterialX package.
- run your stubgen logic to get the files output to the local
MaterialX
folder. - run this step again.
I think this should cover locally packaged plus packages generated via SKBUILD. ( I think think the wheels logic is run afterwards as an additional workflow in github actions ).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which part do you mean exactly? Or the whole code block?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for lack of clarity:
- You need this if block to run to install.
- Then you need your entire stub logic block.
- Then you need this if block again.
@@ -51,6 +51,7 @@ option(MATERIALX_BUILD_SHARED_LIBS "Build MaterialX libraries as shared rather t | |||
option(MATERIALX_BUILD_MONOLITHIC "Build a single monolithic MaterialX library." OFF) | |||
option(MATERIALX_BUILD_USE_CCACHE "Enable the use of ccache to speed up build time, if present." ON) | |||
option(MATERIALX_PYTHON_LTO "Enable link-time optimizations for MaterialX Python." ON) | |||
option(MATERIALX_PYTHON_STUBS "Enable the automated generation of MaterialX Python '.pyi' stub files through mypy's stubgen." OFF) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is set then you need to ensure that MATERIALX_INSTALL_PYTHON is set as well
since your running stubgen off the installed package.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can use https://cmake.org/cmake/help/latest/module/CMakeDependentOption.html for that purpose.
) | ||
endif () | ||
endif() | ||
|
||
if(MATERIALX_INSTALL_PYTHON AND PYTHON_EXECUTABLE AND NOT SKBUILD) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
However to include the stubs in the package itself, You need to repackage.
I think the least number of steps is
- run this install step to produce the locally installed MaterialX package.
- run your stubgen logic to get the files output to the local
MaterialX
folder. - run this step again.
I think this should cover locally packaged plus packages generated via SKBUILD. ( I think think the wheels logic is run afterwards as an additional workflow in github actions ).
I'm a little bit stuck on this. It seems like, whenever SKBUILD is being used, e.g. when building through a
It seems like, to be able to generate the stubs on SKBUILD/ through a Building the stubs already works, at first glance, when building through CMake and installing, without SKBUILD. For the wheels, it could be added as a new step in the workflow (build bindings, build wheels, install, generate stubs, build wheels again with the stubs included). However, I don't really see a way to do it when SKBUILD is in use, or when the bindings are not installed, at least at first glance. One possibility, for a first version, would be to just generate the stubs when building the wheels on CI or when SKBUILD is not in use and the bindings are installed, until we find a better solution for that. If anyone has any ideas, it would be much appreciated! |
Tagging @JeanChristopheMorinPerso as well, for visibility. If you can think of anything, that would be much appreciated too! |
message(\"CMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}\") | ||
if(EXISTS ${_MYPY_STUBGEN_EXECUTABLE}) | ||
execute_process( | ||
COMMAND ${_MYPY_STUBGEN_EXECUTABLE} -p MaterialX --inspect-mode -o ${CMAKE_INSTALL_PREFIX}/python -v --ignore-errors |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if CMAKE_INSTALL_PREFIX
will point at the right thing. See https://scikit-build-core.readthedocs.io/en/latest/cmakelists.html#install-directories.
Hi, apologies, I haven't had time to look into this recently, but I'm planning to come back to this soon, hopefully later this week and ideally wrapping it all up early/mid January. If memory serves me right, I ended up having issues with mypy not identifying the proper files in the right places. This issue goes away once the package has already been installed, but that doesn't help us much here. So there's two options as far as I can tell: 1) identifying a workaround for that (I might be missing the proper folder somehow?) or 2) at least when building on CI for PyPi, installing the Wheels, generating the files, and "updating" (or regenerating?) the Wheels with the stubs. I will try 1) more for the time being, but if that still doesn't work having 2) as a "back-up" plan could be feasible, for an initial solution. I recall I was already being able to generate the stubs and place it within the Wheels when not using scikitbuild. If we end up going for the 2) approach, the only use-case that would be missing, AFAIK, would be a 'pip install .' from the repo, which we could try to add later on. (It also seems my CLA is still not working, either. I will look into that, too.) |
PR for #2024
MATERIALX_PYTHON_STUBS
to enable/disable automated build of Python stubs through mypy stubgenpython/CMakeLists.txt
to account for the logic, if the stubgen executable can be found and if the option is turned onpyproject.toml
to addmypy
as a build dependency and turn on the automated stubs buildingCurrently, this is still a WIP/Draft. When building with a command such as:
cmake -S . -B build -DMATERIALX_BUILD_PYTHON=ON -DMATERIALX_PYTHON_STUBS=ON -DMATERIALX_BUILD_VIEWER=OFF -DMATERIALX_BUILD_GRAPH_EDITOR=OFF -DMATERIALX_BUILD_TESTS=ON -DMATERIALX_TEST_RENDER=OFF -DMATERIALX_WARNINGS_AS_ERRORS=ON -G "Visual Studio 17 2022" -A "x64"; cmake --build build --target install --config Release --parallel 2
the stubs can be found and work properly in the MaterialX installation. However, when building through pip, such as
pip install .
, it seems like it doesn't find some folder or file - I'm assuming the envvars are slightly different when building through pip, and I'm currently not taking that into account. Any help would be appreciated!